A:

RIB stands for RAD Interface Broker - it is RAD's mechanism for expanding and enhancing the system through the use of dynamically-loadable modules. These modules, called RIBs, are designed in conformance with the new RAD Interface Broker (RIB) standard. ASI and FLT files are RIB-based loadable modules.

ASI files are sound codecs - MP3 decoding support is provided by the MSSMP3.ASI file, for example.

FLT files are digital sound filters. All of the default sample-pipeline filters are in the MSSDSP.FLT file. In MSS 7, FLT files can also provide per-voice DirectSound3D/EAX support and matrix (Dolby/SRS) support. This functionality was handled by M3D files in previous releases.

This is all you really need to know about RIB to use Miles, but if you are interesting in the technical underpinnings of RIB, read on...

The RIB standard allows either MSS or the application itself to scan a directory for installable modules, load them, query their properties, and take advantage of the features they offer at runtime, all in a manner that's completely transparent to your application. RIBs deliver many of the same benefits of "component-oriented" design that are commonly associated with more complex and proprietary industry standards such as Microsoft's COM model, but on an open, cross-platform basis, and with several key features designed to avoid many of the headaches that eventually come to plague users of other runtime object models.

As with most component-based models in use today, RIB components represent individual functions and data elements as collective members of named interfaces. Unlike more familiar object models such as those associated with MS COM and even C++ itself, however, an application's view of a particular RIB interface and its elements is determined completely by the application itself, and not the RIB component provider or any of its header files. The MSS RIB manager implements true dynamic binding at no additional cost in runtime performance. By way of illustration, three different ways to instantiate the same object might look like:

C++ With Static Binding

MyStream = new MP3Stream;

MS COM With Runtime Binding

MP3StreamFactory->QueryInterface(IID_Stream,
                                 (void **) &MyStream);

RAD Interface Broker With Runtime Binding

STR_OPEN STR_open;
...
HPROPERTY OUTPUT_SAMPLE_RATE
...
RIB_INTERFACE_ENTRY MyStreamInterface[] =
{
   FN(STR_property),
   FN(STR_open),
   FN(STR_close),
   FN(STR_process),
   PR("Output sample rate",    OUTPUT_SAMPLE_RATE),
   PR("Output sample width",   OUTPUT_BITS),
   PR("Output channels",       OUTPUT_CHANNELS)
}
HSTREAM STR = RIB_find_file_provider("Audio stream",
                                     "Input file types",
                                     "*.MP3");
RIB_request(STR,
           "Audio stream",
            MyStreamInterface);
MyStreamHandle = STR_open();

It's apparent at a glance that the RIB-based example is, if nothing else, more complex. What benefits are being gained with all that extra code? The answer lies in a fundamental aspect of the RIB system's design: RIB interfaces specify content, not structure. RIB components never reveal the exact layout of their interfaces to the application. A RIB interface name is only used to refer to a collection of available, related functions and data properties. Unlike a C++ class, a RIB interface does not expose implementation details which have to be artificially segregated from the outside world with "private" or "public" labels. And unlike an MS COM interface, a RIB interface does not introduce dangerous dependencies on the underlying language's virtual-function table model, including the number of functions an interface provider offers and the order in which its function prototypes appear in a class declaration. As suggested by the example above, each RIB application is able to specify its own view of the functions and data exposed by its component providers. The binding of the provider's resources with the application's declarations takes place dynamically, via the RIB_request function. There are several advantages to this approach:

- No more obsolete header files. A RIB component's header file contains only the typedef'ed prototypes for the functions exported by the component at its time of release. The application declares variables of these types to receive function pointers when RIB_request is called to resolve its requested functions by name. Data properties are resolved in a similar manner, through the use of tokens which are passed down from the provider to the caller via RIB_request.

- No more broken interfaces. A RIB interface does not contain or imply any implementation details such as the order in which its functions appear in an internal virtual-method table. Consequently, new functions and data members may be exposed in subsequent releases, without "breaking" any existing application compiled with an older version of the component's header file. Similarly, different providers of the same interface (e.g., an MPEG audio decoder and an IMA ADPCM audio decoder) can export provider-specific properties and functions, which the application can either enumerate or ask for explicitly at runtime. Applications are also free to request functions and properties which may not be supported by all providers of a given interface, taking advantage of optional features when available and degrading gracefully otherwise.

- Full runtime browsability. All communication between RIB components and their calling applications takes place via functions and properties whose names are presented as plain-text ASCII strings. This applies as well to the names of the components' interfaces themselves. The RIB manager API allows the names, members, and types of all interface elements to be enumerated in a standardized fashion, making it possible for general-purpose component browsers to be developed for all providers of a given interface.

What does this mean to you, as the creator of your own MSS applications? The good news is that we've made it easy for you to take advantage of the new RIB providers without getting involved in the details of the RIB component model. MSS's API has been expanded to make access to both the 3D audio and MPEG compression feature sets as painless as possible. Most application authors will never come into direct contact with the RIB manager API that's built into MSS. For the curious, however, the complete RIB API documentation is available in RIB.H. Specific RIB interface specs used by Miles are found in MSS.H.

In short, RAD believes that the component-oriented RAD Interface Broker model is the best way to make sure that MSS grows with your needs. We feel it's one of the more exciting features of the new system, even though its implications may be lost amidst the excitement of the new features and tools!